Un alternative serait d'avoir la même (ou quasiment la même) structure de donnée dans domains.csv et dans urls.csv (et donc plus urls.txt) :

name,SIRET,type,sources,script

L'avantage serait d'éviter d'avoir à choisir sur quel aspect on fait le découpage : ça permettrait de chercher une URL par sources, ou par SIRET en plus de pouvoir la chercher par type.

Bien vu ! Ça pourra faire l'objet d'une autre PR.

Là le but est uniquement de mettre à dispo les fichiers urls-*.txt. Est-ce OK pour toi pour merger ?

[après les vacances]

Bien vu ! Ça pourra faire l'objet d'une autre PR.

Oui mais y'a-il un grand intérêt d'avoir un commit qui découpe un fichier (en ~35 fichiers !) pour enchaîner avec une PR qui l'unifie à nouveau ?

oui :) Ça permet :

• d'avoir dès maintenant les fichiers urls-*.txt dans master
• de découpler la mise à dispo de ces fichiers du refacto avec CSV

avoir dès maintenant les fichiers urls-*.txt dans master

Je n'ai pas retenu que c'était un objectif, selon les notes de la réunion l'objectif est un seul domains.csv et un seul urls.txt :

Jeux de données dérivés:

• urls.txt: HTTP(S)
• mx.txt
• version_super_verifiee_pas_de_phishing.txt

Mais j'entend ton besoin d'avoir un découpage par type de structure, si je me souviens bien tu en avais fait la demande à l'oral et quelqu'un (si ce n'est pas moi) t'avait répondu « tu pourras faire une jointure ».

On parlait probablement de join qui permet de faire une jointure sur deux fichiers, mais la réponse à peut-être été lancée un peu vite, ce n'est pas si simple à appliquer ici car d'un côté on a des URLs et de l'autre des domaines, bon ça se fait, mais c'est pas agréable :

$ join -t, <(sed 's#^https\?://\(.*\)$#\1,\0#' urls.txt | sort) <(sort domains.csv)

Avec grep c'est un poil plus lisible, mais toujours pas agréable :

$ grep -Ff<(grep Commune domains.csv | cut -d, -f1 | sed s#^#//#) urls.txt

Par contre vu qu'on aura le type de structure dans domains.csv tu pourras faire :

grep Commune domains.csv

pour avoir toute les Commune, et là ça me paraît agréable. Tu pourras faire :

grep '200.OK.*Commune' domains.csv

pour avoir toutes les communes qui répondent en 200 OK en HTTP, ça reste lisible.

C'est le fait que ça devienne simple d'obtenir ces listes me fait penser qu'on ne devrait pas versionner tous ces fichiers.

J'ai presque envie de proposer de ne plus stocker, urls.txt du tout vu que c'est presque un grep 200.OK domains.csv mais on s'éloigne du sujet.

Merci @JulienPalard pour les lignes de commandes que je ne connaissais pas !

Le fait d'avoir le ou les fichiers urls.txt dans le dépôt possède une grande valeur : "c'est le jeu de donnée de la DINUM". La recette de cuisine intéresse les développeurs, la liste des URLs intéresse tout le monde.

la liste des URLs intéresse tout le monde

Oui, mais je suis réticent à versionner toutes les listes d'URLs (je suis le seul ?). Pour ton usage tu en as besoin par type, mais pour un autre usage le besoin est peut-être sur un autre aspect, et j'ai peur de voir le nombre d'artefacts versionnés exploser.

D'ailleurs @rdubigny côté publication sur data.gouv.fr, préconises-tu de versionner tous les artefacts qu'on publie, ou peut-on se contenter de versionner le script qui génère les artefacts ?

Ça permettrai peut-être de trouver un compris : la « recette de cuisine » côté github pour les devs, les listes côté data.gouv.fr pour les ré-utilisateurs ?

Bien vu de séparer les lieux de publication ! Ça répondrait à mon besoin. Pour moi il est important de rendre nos listes utilisables dès maintenant, et à tout le monde :)